-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: recursive dynamic containers #224
Merged
maharshivpatel
merged 8 commits into
frappe:develop
from
maharshivpatel:recursive-dynamic-containers
May 1, 2024
Merged
feat: recursive dynamic containers #224
maharshivpatel
merged 8 commits into
frappe:develop
from
maharshivpatel:recursive-dynamic-containers
May 1, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of computing layout and then checking for overlaps, we can check for overlaps while computing layout. also, fixed bug in auto header / footer height calculation causing overlapping error. added 1px on both sides ( top/bottom ) of the table element.
moved computeRowElementDimensions & computeColumnLayout function calls inside computeRowLayout. this is cleaner code and will be better design to allow recursive layout parsing.
- Current Logic for dynamic containers is not recursive. It loops through the elements and compute possible rows then it loops again and compute possible columns. - This was less efficient, less flexible, and not recursive. Impact will be more apparent when we have multi pages and 100s to Elements. - Now, I have added recursive logic to handle nested dynamic containers. current implementation have 2 functions computeRowLayout and computeColumnLayout. this functions that call each other to create a recursive layout until it's not possible. first, we compute main layout where we split it into 3 sections ( header, body, footer). then we run these functions on each of these sections and save the layout. In theory, we can set dynamicHeight for any element as long as it's not overlapping.
if rectangle is only ( basically no element is overlapping with it) or last element inside row or column, row and column layout is computed for children. - if rectangle is overlapping with other element and we make it relative placement of other element will be broken so for now it is set to compute layout as per above condition created patch that will convert isDynamicHeight Boolean to heightType with value "fixed" or "auto". updated default objects and control in Properties Panel. changed schema version number to 1.2.0 as schema is changed and is incompatible with old formats (1.1.0) we need to handle old formats. updated jinja render template - modified relative_containers to be recursive - updated all templates to use heightType properties - updated logic to include min-height - added logic for backwards compatibility. - also introduced dynamic height for static text if it has parseJinja enabled. - updated rectangle template to be dynamic height misc: is_older_schema now handles really old formats which don't have schema_version reverted styles for relative column
added logic to run patches on output print_formats that are used by jinja when required
🎉 This PR is included in version 1.3.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current Logic for dynamic containers is not recursive. It loops through the elements and compute possible rows then it loops again and compute possible columns.
This was less efficient, less flexible, and not recursive. Impact will be more apparent when we have multi pages and 100s to Elements.
Now, I have added recursive logic to handle nested dynamic containers. current implementation have 2 functions computeRowLayout and computeColumnLayout. this functions that call each other to create a recursive layout until it's not possible. first, we compute main layout where we split it into 3 sections ( header, body, footer). we run these functions on each of these sections and save the layout.
In theory, we can set dynamicHeight for any element as long as it's not overlapping.